Wide area networks (WAN) and local area networks (LAN) are being increasingly relied upon to carry voice communications in packet format. Technologies such as voice over intenet protocol (VoIP), voice over frame relay (VOFR) and voice over asynchronous transfer mode (VoATM) have been adopted for carrying the packetized voice signals. Such transmission generally provides for substantially reduced costs over traditional circuit switched voice transmissions. A particular application where packet voice systems have proved advantageous is for use by an enterprise to communicate between facilities and thereby avoid traditional circuit switched phone network toll charges.
To facilitate carrying of voice in packet format in such an application, gateways may be interfaced between existing phone systems and data networks. The gateways may convert signals between standard phone signals and packet based format. The gateways also provide routing instructions for the call signals, as well as providing various other functions.
FIG. 1 illustrates a simplified enterprise based network configuration for sending voice in a packet format. Acme Co. phone 2 in Chicago is connected through PBX 4 for calls to external phone 6 over LEC 8 (“Local Exchange Carrier”) 8. LEC charges of course apply to such calls. Packet based transmission of calls can be made over an Acme Co. data network to other intra-company phones to avoid tolls associated with use of LEC 8, IXC 10 (“Inter Exchange Carrier”), and LEC 12. For an intra-company call from Acme Chicago phone 2 to Acme Houston phone 14, for example, gateway 16 converts the call signal to a packet format, and routes the call over Acme WAN 18 to Houston gateway 20. Gateway 20 in turn converts the call back to a standard format and sends it to PBX 22 for transmittal to phone 14. Calls between Acme phones 2 and 14 can thereby be made without associated LEC or IXC charges.
In addition, a method of calling off-company-network (“off-net”) phones known as “leaking” can be used to save additional fees. As an example, leaking may be used to complete a call from Acme Chicago phone 2 to external phone 24 located near Houston without incurring charges from LEC 8 or IXC 10. The call to external phone 24 from phone 2 is converted to a packet format at gateway 16, routed over WAN 18 to Acme Houston, converted back to a standard format at gateway 20, and routed to PBX 22. Gateway 20 then instructs PBX 22 to send the call over LEC 12 to external phone 24. Only charges associated with LEC 12 are thus encountered.
In order to process calls for intra-company or leaking purposes, the gateways 16 and 20 may use what is generally known as a dial plan. A dial plan provides instruction for assigning network addresses and routing instructions to particular phone extensions, so that a dialed phone number may be translated into a data network address and route by the network. These routing instructions and addresses may be referred to as “dial peers”.
The dial plan thereby processes incoming calls and provides instructions on how to route the call to a desired destination.
Configurations as illustrated in FIG. 1 and as described above are generally known in the art. There are several heretofore-unresolved problems with such configurations and methods, however .
A first problem involves a scenario that is known as “re-direct”. When a call is routed from PBX 4 to router 16 for transmission over WAN 18, router 16 may determine that no downstream capacity is available to carry the call (if for instance router 20 or some element in WAN 18 is down). This may result in a fast busy signal to the caller, with no logic provided for rerouting the call back to PBX 4 for alternate path transmission over LEC 8.
Attempts to resolve this problem have been made. Specifically, some recently commercially available PBX's do provide logic for redirect functionality. In addition, upgrade “kits” can be incorporated in existing PBX's to enable these capabilities. These new PBX's and/or the upgrade kits, however, tend to be expensive. Many packet-based transmission configurations are retro-fitted onto existing PBX's that do not have this functionality. Replacement of the existing PBX with the more expensive newer model is not practical. This proposed solution is therefore disadvantageous.
A second solution to this problem has been proposed. Specifically, it has been proposed to connect gateway 16 to LEC 8 as illustrated by dashed line of FIG. 1. Calls that would otherwise be terminated because of a downstream problem may now be re-routed over LEC 8 by gateway 16. This second proposed solution, however, leaves several problems unresolved. As a first, it will require a dial plan providing re-direct logic. To date, no adequate dial plans are known. Also, the proposed solution requires a second connection to LEC 8. This connection requires effort to install and maintain, and requires a monthly charge. In addition, this second proposed solution may require some functionality and programming of PBX 4. Some PBX's, particularly older PBX's, may not be able to be configured for this solution.
Further, even if the PBX has this functionality, programming of the PBX requires effort and knowledge of the system. This places a burden on the gateway installer, particularly when considering the multiplicity of existing PBX's. It is impractical to burden the gateway installer with acquiring working knowledge of all of these different PBX's.
Another unresolved problem with the general configuration of a packet based phone system as illustrated in FIG. 1 has to do with leaking. Currently, leaking a call from phone 2 to external phone 14 requires interface with and transmission through PBX 22, as discussed above. This inevitably requires programming and physical configuration of PBX 22. This in turn requires working knowledge of PBX 22. As discussed above, such a requirement is disadvantageous in that a multiplicity of PBX's exists. It is burdensome and impractical for the gateway installer to have working knowledge of all different existing PBX's.
In addition to problems associated with re-direct functionality, further problems in the art relate to dial plans. Many dial plans that have been proposed for solving packet based voice system functionality problems require special dialing instructions. As an example, a caller from phone 2 may be required to dial “#99” to signal to PBX 4 or to gateway 16 that the call should be routed over WAN 18. Such dial plans are disadvantageous in that any additional dialing requirements for the user are inconvenient and often result in a lower utilization rate. Again referring to the Acme configuration of FIG. 1 by way of example, an Acme employee may not remember or care to go to the effort of learning dial plan dialing instructions for using the packet based voice system, and may instead simply go on using the familiar PSTN based dialing and thereby not take advantage of any cost savings available.
Heretofore unresolved problems therefore exist with regards to providing functionality for packet based phone configurations.